Splicing into an active TLS session without a certificate or private key

ABSTRACT

An origin server selectively enables an intermediary (e.g., an edge server) to shunt into and out of an active TLS session that is on-going between a client and the origin server. The technique allows for selective pieces of a data stream to be delegated from an origin to the edge server for the transmission (by the edge server) of authentic cached content, but without the edge server having the ability to obtain control of the entire stream or to decrypt arbitrary data after that point. The technique enables an origin to authorize the edge server to inject cached data at certain points in a TLS session, as well as to mathematically and cryptographically revoke any further access to the stream until the origin deems appropriate.

BACKGROUND

1. Technical Field

This application relates generally to secure network-basedcommunications using cryptographic protocols such as Transport LayerSecurity (TLS).

2. Brief Description of the Related Art

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer(SSL), are cryptographic protocols that provide Internet communicationsecurity. They use asymmetric cryptography for authentication and keyexchange, symmetric encryption for confidentiality, and messageauthentication codes for message integrity. TLS/SSL is initialized at asession layer then works at a presentation layer. In particular, firstthe session layer has a handshake using an asymmetric cipher toestablish cipher settings and a shared key for that session. Thereafter,a presentation layer encrypts the rest of the communication using asymmetric cipher and that session key. In both models, TLS and SSL workon behalf of the underlying transport layer, whose segments carryencrypted data. TLS is an IETF standards track protocol, defined in RFC5246 and RFC 6176.

Distributed computer systems are well-known in the prior art. One suchdistributed computer system is a “content delivery network” (CDN) or“overlay network” that is operated and managed by a service provider.The service provider typically provides the content delivery service onbehalf of third parties (customers) who use the service provider'sshared infrastructure. A distributed system of this type typicallyrefers to a collection of autonomous computers linked by a network ornetworks, together with the software, systems, protocols and techniquesdesigned to facilitate various services, such as content delivery, webapplication acceleration, or other support of outsourced origin siteinfrastructure. A CDN service provider typically provides servicedelivery through digital properties (such as a website), which areprovisioned in a customer portal and then deployed to the network. Adigital property typically is bound to one or more edge configurationsthat allow the service provider to account for traffic and bill itscustomer.

For a traditional RSA-based TLS session, the two sides of a connectionagree upon a “pre-master secret” (PMS) which is used to generate theparameters for the remainder of the session. Typically, the two sidesuse RSA asymmetric encryption to establish the pre-master secret withoutexchanging the actual value in plaintext. In operation, the SSL clientgenerates the pre-master secret and encrypts it with the TLS server'spublicly available RSA key. This generates an encrypted pre-mastersecret (ePMS), which is then provided to the TLS server. The TLS serverhas a private decryption key, which is then used to decrypt theencrypted pre-master secret. At this point, both the client and theserver have the original pre-master secret and can use it to generatethe symmetric key used for actual encrypted and secure data exchange.Decrypting the encrypted pre-master secret is the only time in the TLSconnection that the private key is needed. This decryption occurs at aso-called TLS termination point. Where a CDN is used to facilitatedelivery of secure content, the TLS termination point will be located inthe CDN.

Some CDN customers are not comfortable sharing their private TLS (RSA,DSA, etc.) keys with the CDN service provider. Further, some customersmay require an additional caveat that certain data and requests never bedecrypted by the CDN at any point in any transaction, and that the datatransmitted by the CDN on behalf of the customer is provably andverifiably authentic.

BRIEF SUMMARY

This disclosure describes a technique that allows for selective piecesof a data stream to be delegated from a customer to a CDN for thetransmission of authentic cached content without the CDN having theability to obtain control of the entire stream or to decrypt arbitrarydata after that point. The technique enables a customer to authorize theCDN to inject cached data at certain points in a TLS session, as well asto mathematically and cryptographically revoke any further access to thestream until the origin (the customer) deems appropriate.

The foregoing has outlined some of the more pertinent features of thesubject matter. These features should be construed to be merelyillustrative. Many other beneficial results can be attained by applyingthe disclosed subject matter in a different manner or by modifying thesubject matter as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the subject matter and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 is a block diagram illustrating a known distributed computersystem configured as a content delivery network (CDN);

FIG. 2 is a representative CDN edge machine configuration; and

FIG. 3 is a representative active TLS session among a client, an edgeserver, and an origin server and into which the edge server, withpermission, is enabled to shunt into without a certificate and/orprivate key according to this disclosure.

DESCRIPTION

In a known system, such as shown in FIG. 1, a distributed computersystem 100 is configured as a content delivery network (CDN) and isassumed to have a set of machines 102 a-n distributed around theInternet. Typically, most of the machines are servers located near theedge of the Internet, i.e., at or adjacent end user access networks. Anetwork operations command center (NOCC) 104 manages operations of thevarious machines in the system. Third party sites, such as web site 106,offload delivery of content (e.g., HTML, embedded page objects,streaming media, software downloads, and the like) to the distributedcomputer system 100 and, in particular, to “edge” servers. Typically,content providers offload their content delivery by aliasing (e.g., by aDNS CNAME) given content provider domains or sub-domains to domains thatare managed by the service provider's authoritative domain name service.End users that desire the content are directed to the distributedcomputer system to obtain that content more reliably and efficiently.Although not shown in detail, the distributed computer system may alsoinclude other infrastructure, such as a distributed data collectionsystem 108 that collects usage and other data from the edge servers,aggregates that data across a region or set of regions, and passes thatdata to other back-end systems 110, 112, 114 and 116 to facilitatemonitoring, logging, alerts, billing, management and other operationaland administrative functions. Distributed network agents 118 monitor thenetwork as well as the server loads and provide network, traffic andload data to a DNS query handling mechanism 115, which is authoritativefor content domains being managed by the CDN. A distributed datatransport mechanism 120 may be used to distribute control information(e.g., metadata to manage content, to facilitate load balancing, and thelike) to the edge servers.

As illustrated in FIG. 2, a given machine 200 comprises commodityhardware (e.g., an Intel Pentium processor) 202 running an operatingsystem kernel (such as Linux or variant) 204 that supports one or moreapplications 206 a-n. To facilitate content delivery services, forexample, given machines typically run a set of applications, such as anHTTP proxy 207 (sometimes referred to as a “global host” process), aname server 208, a local monitoring process 210, a distributed datacollection process 212, and the like. For streaming media, the machinetypically includes one or more media servers, such as a Windows MediaServer (WMS) or Flash server, as required by the supported mediaformats.

A CDN edge server is configured to provide one or more extended contentdelivery features, preferably on a domain-specific, customer-specificbasis, preferably using configuration files that are distributed to theedge servers using a configuration system. A given configuration filepreferably is XML-based and includes a set of content handling rules anddirectives that facilitate one or more advanced content handlingfeatures. The configuration file may be delivered to the CDN edge servervia the data transport mechanism. U.S. Pat. No. 7,111,057 illustrates auseful infrastructure for delivering and managing edge server contentcontrol information, and this and other edge server control informationcan be provisioned by the CDN service provider itself, or (via anextranet or the like) the content provider customer who operates theorigin server.

The CDN may include a storage subsystem, such as described in U.S. Pat.No. 7,472,178, the disclosure of which is incorporated herein byreference.

The CDN may operate a server cache hierarchy to provide intermediatecaching of customer content; one such cache hierarchy subsystem isdescribed in U.S. Pat. No. 7,376,716, the disclosure of which isincorporated herein by reference.

The CDN may provide secure content delivery among a client browser, edgeserver and customer origin server in the manner described in U.S.Publication No. 20040093419. Secure content delivery as describedtherein enforces SSL-based links between the client and the edge serverprocess, on the one hand, and between the edge server process and anorigin server process, on the other hand. This enables an SSL-protectedweb page and/or components thereof to be delivered via the edge server.

As an overlay, the CDN resources may be used to facilitate wide areanetwork (WAN) acceleration services between enterprise data centers(which may be privately-managed) and third party software-as-a-service(SaaS) providers.

In a typical operation, a content provider identifies a content providerdomain or sub-domain that it desires to have served by the CDN. The CDNservice provider associates (e.g., via a canonical name, or CNAME) thecontent provider domain with an edge network (CDN) hostname, and the CDNprovider then provides that edge network hostname to the contentprovider. When a DNS query to the content provider domain or sub-domainis received at the content provider's domain name servers, those serversrespond by returning the edge network hostname. The edge networkhostname points to the CDN, and that edge network hostname is thenresolved through the CDN name service. To that end, the CDN name servicereturns one or more IP addresses. The requesting client browser thenmakes a content request (e.g., via HTTP or HTTPS) to an edge serverassociated with the IP address. The request includes a host header thatincludes the original content provider domain or sub-domain. Uponreceipt of the request with the host header, the edge server checks itsconfiguration file to determine whether the content domain or sub-domainrequested is actually being handled by the CDN. If so, the edge serverapplies its content handling rules and directives for that domain orsub-domain as specified in the configuration. These content handlingrules and directives may be located within an XML-based “metadata”configuration file.

More generally, the techniques described herein are provided using a setof one or more computing-related entities (systems, machines, processes,programs, libraries, functions, or the like) that together facilitate orprovide the described functionality described above. In a typicalimplementation, a representative machine on which the software executescomprises commodity hardware, an operating system, an applicationruntime environment, and a set of applications or processes andassociated data, that provide the functionality of a given system orsubsystem. As described, the functionality may be implemented in astandalone machine, or across a distributed set of machines. Thefunctionality may be provided as a service, e.g., as a SaaS solution.

Splicing into an Active TLS Session without a Certificate or Private Key

With the above as background, the subject matter of this disclosure isnow described. Familiarity with TLS handshaking is presumed.

As used herein, an “edge server” refers to a CDN (overlay network) edgemachine. For a given customer, the CDN service provider may allow a TCPconnection to originate from a client (e.g., an end user browser, ormobile app) and connect to an edge machine representing the customer ona virtual IP address (VIP) assigned to the customer, or a general VIPthat allows for discovery of the intended customer. For purposes of thisdisclosure, it is assumed that this edge machine does not have thecustomer's private key or the customer's certificate. Nevertheless, andas will be seen, the technique of this disclosure enables the customerorigin to request that the CDN shunt into and out of a particularTLS-secured session, and the CDN can guarantee that it is complying withthis request.

As illustrated in FIG. 3, in the typical interaction scenario, an enduser client browser or mobile app 300 is associated with a customerorigin server (or “origin”) 302 via the intermediary of an overlaynetwork edge machine server instance 304 (sometimes referred to as an“edge server”). The terms “origin” or “edge” are not intended to belimiting.

The following provides details regarding the TLS handshake between theclient 300 and the origin 302. As noted above, the reader's familiaritywith the TLS Specification is presumed. The edge machine server instance304 passes handshake messages through directly to the origin 302, andvice versa. Once the handshake is complete, the origin 302 and client300 will have negotiated a Pre-Master Secret and exchange random numbervalues for the session. According to the TLS 1.2 Specification Section8.1, each side will have converted its Pre-Master Secret into a MasterSecret using an agreed-upon pseudo-random function (PRF), such as anHMAC variant. The TLS 1.2 Specification Section 6.3 notes that thisMaster Secret is then converted into a larger key block, which is thenused to calculate the following TLS items: client_write_MAC_key (the keythat be used as input to the client's sent data message authenticationcodes (MACs)), wherein each TLSCipherText record has a MAC that verifiesthe data in the record is authentic and unchanged); server_write_MAC_key(the key that will be used as input to the server's sent data MACs);client_write_key (the key that will be used for the agreed-upon bulkencryption cipher for client sent data; and server_write_key (the keythat will be used for the agreed-upon bulk encryption cipher for serversent data). Other items may be calculated but, for purposes of thisprotocol, are not relevant.

The following provides details regarding the handling of encryptedrequests and responses without the TLS splicing (shunting) technique ofthis disclosure. The requests at this stage are encrypted using theparameters from the TLS handshake described above. In a typicaloperation, the CDN edge server 304 receives the TLS records (thatrepresent the request) from the client 300 and simply forwards themalong to the origin 302, unable to read them due to the encryption. Whenthe response data (from the origin) is private and should not be sharedwith the CDN, the origin 300 responds back to the edge server 304 usingthe conventional TLS mechanisms. The edge server 304 receives this dataand simply passes it through to the client 300, again unable to read itdue to the encryption. At this point, and without reference to thetechniques of this disclosure, the edge server 304 thus is simply actingas a pass-through TCP proxy. It can neither decrypt data nor contributedata to the TLS session.

According to this disclosure, the origin 302 may selectively upgrade theedge server 304 to have one or more different capabilities with respectto the TLS session. This is sometimes referred to herein as “splicing”or “shunting” into (and out of) the active TLS session because the edgeserver, which is otherwise just acting as a pass-through, is enabled tohave visibility into the data stream itself. This capability allows forselective pieces of a data stream to be delegated from a customer (theorigin) to the CDN edge server for the transmission (from the edgeserver) of authentic cached content but without the CDN having theability to obtain control of the entire stream or to decrypt arbitrarydata after that point. The technique enables a customer to authorize theCDN to inject cached data at certain points in a TLS session, as well asto mathematically and cryptographically revoke any further access to thestream until the origin (the customer) deems appropriate. Thesplicing/shunting capability is managed (controlled) by the origin;thus, it is not an operation that the edge server carries out on its ownvolition.

A first upgrade is a Decryption Upgrade. This specific capability allowsthe edge server 304 to decrypt data but not to contribute data to theTLS session. The origin 302 performs this upgrade by communicating tothe edge machine the value for the current client_write_key (if it isdesired to enable the edge server to be able to decrypt clientrequests), the value for the current server_write_key (if it is desiredto enable the edge server to be able to decrypt origin responses), orboth. The origin may communicate the client_write_key and/or theserver_write_key to the edge server either directly or through someout-of-band manner. In any such scenario, preferably MAC keys are notshared by the origin. This upgrade enables the edge machine to decryptTLS records, but the edge server still is restricted from contributingnew data (or changing data) on its own, as it does not possess thenecessary keys to produce the MACs that are appended to the end of theTLS records. Thus, the Decryption Upgrade enables the edge servermachine to see into the TLS session but not to contribute or change dataflowing within that session. Data continues to flow, and the edgemachine is able to decode the channels into which it has been givenaccess by the origin.

If the CDN edge machine has been given access (as described above) towatch the client sent data stream, the edge server can determine if itsees a request HTTP method, a particular URL, and/or one or more headersfor which it can serve a response (from its local cache). If such a hitoccurs, preferably the edge server sends to the origin upstream the TLSrecord together with a hash of the entire cached object (or some definedportion) it can serve as a response. This hash may be pre-computed andstored with the object, e.g., when it is initially cached, or it may becomputed on-the-fly.

Alternatively, if the edge server 304 has not been given access to watchthe client sent data stream, the origin 302 may initiate a Cache HitRequest to the edge servers for requests it receives that the originbelieves may be serve-able from the edge server cache. This messagewould contain the URL, headers, and any other information that the edgeserver needs to determine if it has (in cache) the response to therequest. If the edge server does contain a cached response, it may sendthe hash of the object back (as described above), and the origin wouldthen make a determination of what action to take next.

Another capability that may be implemented is the ability of the origin302 to control the edge server to implement a one-time write grant. Thisis sometimes referred to herein as a One-Time Write Grant Upgrade. Thefollowing describes this process. The capability may be implemented whenthe origin, upon receiving notice (from the edge server) that the edgeserver can service the current request from cache. In operation, theorigin checks the following: (i) is the response data on the edge serverfresh (in other words, does its hash match the origin's current hash?),and (ii) is the request from cache service-able from the edge accordingto the origin's (the customer's) security policy? If both conditions aretrue, then the origin may upgrade the edge server to perform one-timewrite grant by providing the edge server the server_write_key (thusenabling the edge server to be server decrypt-able). To this end, theorigin 302 scans over the data (e.g., in an agreed-upon file (16 KB)block by (16K) block manner), generating the TLS records it would havesent had the edge server not been present. More specifically, for eachrecord, the origin generates the MAC for the record using the TLScompressed record data, the sequence number that would be correct atthat point, and the server_write_MAC_key. For this upgrade, the MACsgenerated by the origin are then sent by the origin 302 to the edgeserver 304. On the edge server, the local system loads the agreed-uponfile that matches the hash and, for each 16 KB of plaintext that itreads, it converts that plaintext to a TLS compressed record using anagreed-upon compression algorithm. For each of these records, the edgeserver now generates a TLSCipherText message using the methods describesin the TLS Specification Section 6.2.3. For example, using theserver_write_key (that the origin shares), the edge server encrypts theTLS compressed record fragment, origin-generated MAC, and added paddingdata for block boundaries (if using a CBC block cipher). Once the recordis created, the edge server 304 sends it to the client 300. From theclient's perspective, nothing out of the ordinary has occurred. Once theagreed-upon data has been fully sent, however, the edge server is out ofMACs and thus can no longer participate in the conversation.

Preferably, the one-time write grant described above expires after theedge server 304 has written the entire file. The decryption keys,however, do not expire. Once the edge server had been given decryptionkeys (whether from a one-time write grant or otherwise), it can continueto view the stream's contents in the specific direction for which it hasa key. The origin 302, however, may wish to revoke (from the edgeserver) this visibility capability. A determination by the origin serverto revoke the visibility may occur at any particular moment, e.g., basedon what the origin is about to send or what it expects to receive fromthe client 300. A revocation of rights capability thus is also enabled,once again under the control of the origin. Preferably, revocation iscarried out through renegotiation. In particular, according to thisprotocol, preferably each request flows completely back to the origin302 before the origin decides either to service the request itself orgive the edge server the one-time write grant described above. If thedecision is to serve the content itself (i.e. in a private mannerwithout the edge server being able to view in a meaningful way the datagoing forward), and if the edge server currently has keys that makesthis impossible, the origin 302 issues a TLS HelloRequest message. Thismessage asks the client 300 to begin a renegotiation in which one ofthree options must occur, referred to as follows: (i) efficientrenegotiation, (ii) long renegotiation, or (iii) connection termination.Each of these options is described below.

The efficient renegotiation option works as follows. Upon receiving theTLS HelloRequest message, the client 300 is allowed to request theresumption of a session that it and the origin used previously and thatwas identified in a SessionID field in the origin's original TLSServerHello message. Upon receipt of a TLS HelloRequest message, someclients will not only attempt session resumption, but they will actuallyattempt to perform the resumption using the current session ID that isalready in use. As described in TLS 1.2 Specification Section F.1.4,session resumption establishes new pseudo-random numbers and thus newkeys. Therefore, clients that perform this action change the underlyingkeys, thereby removing the decryption capability of the edge server inboth directions.

Another option to revoke the edge server's view rights is longrenegotiation, which is just a full handshake. This option dumps thecurrent session and involves asymmetric cryptography for key exchange.By changing the underlying keys, this option revokes decryption accessfor the edge server in both directions.

The final option, connection termination, works as follows. This optionmay be used to revoke the decryption rights at the edge machine if theclient 300 refuses to renegotiate. In this event, the origin 302 mayterminate the connection to force a reconnect (and full handshake).Methods that are not idempotent (e.g., POST) are not issued onsubsequent requests on a persistent connection (due to the possibilityof a timeout occurring on the origin and a shutdown of the connection).Thus, they are inherently safe from the close. For other methods thatare idempotent (e.g., GET), and to maintain proper timeout semantics,preferably the client reconnects and replays the request if a persistentconnection is closed.

Regardless of which revocation option is initiated, the result is thatthe edge server receives an indication that is generated in associationwith the renegotiation. This indication typically is in the form of dataindicative of an initiated or completed renegotiation of the active TLSsession, and that renegotiation has the effect of revoking the edgeserver's then-current decryption access to the data stream.

When it is necessary for the edge server to communicate with the originserver (or vice versa) as described herein, such communication may occurover the TLS connection, or over a distinct channel (e.g., a separateTCP connection).

Thus, according to this disclosure, the above-described methods may beused by the origin to exploit the TLS protocol to provide: granting ofdecryption visibility to the edge server for client sent data, grantingof decryption visibility to the edge server for server sent data,revoking from the edge server of decrypting visibility for client sentdata, revoking from the edge server of decryption visibility for serversent data, and granting to the edge server one-time write authority,preferably for specific authorized data over specific byte sequences inthe stream.

As described herein, the origin server manages splitting or shunting ofthe active TLS session to enable the edge server visibility; this is thetypical operation in the context of a CDN wherein the CDN customeroperates the origin server and the client is an end user requestingcontent. In other scenarios, however, the control over the splittingoperation may be managed by the client instead of the origin server, orby both the client and the origin server.

The references to TLS 1.2 are merely exemplary. The techniques describedherein may be generalized for use with any cryptographic protocol thatuses both (i) asymmetric cryptography to exchange unidirectionalsymmetric keys, and (ii) separate authentication code keys. Thus, thetechniques may be used to shunt an intermediary into an active sessionfor various SSL versions, next-generation TLS, and other such protocols.

The reference to HTTP-based requests and responses is merely exemplaryas well. The technique for enabling the intermediary to have visibilityinto the active cryptographic session may be used with any type ofprotocol, and the one-time write grant function may be used with anyrequest and response-driven protocol (and not just HTTP).

The techniques described above are not limited to the intermediary beingan edge server within an overlay network; thus, the above methods shouldbe generalized with respect to any third party entity (system, device,machine, program, process, execution thread, etc.) and not just the CDNedge server as described.

The approach provides the overlay network and its customers manyadvantages. It removes from the overlay network all asymmetriccryptography for the customer, thereby significantly reducing processingand storage expense and requirements. It removes from the overlaynetwork all private keys for the customer. It removes from the overlaynetwork all public certificates for the customer. It provides dataauthenticity and integrity guarantees to cached items. The approach asdescribed places the origin in complete control of what is private datawithout the overlay network provider's explicitly-required assistance.

While the above describes a particular order of operations performed bycertain embodiments of the invention, it should be understood that suchorder is exemplary, as alternative embodiments may perform theoperations in a different order, combine certain operations, overlapcertain operations, or the like. References in the specification to agiven embodiment indicate that the embodiment described may include aparticular feature, structure, or characteristic, but every embodimentmay not necessarily include the particular feature, structure, orcharacteristic.

While the disclosed subject matter has been described in the context ofa method or process, the subject disclosure also relates to apparatusfor performing the operations herein. This apparatus may be speciallyconstructed for the required purposes, or it may comprise ageneral-purpose computer selectively activated or reconfigured by acomputer program stored in the computer. Such a computer program may bestored in a computer readable storage medium, such as, but is notlimited to, any type of disk including an optical disk, a CD-ROM, and amagnetic-optical disk, a read-only memory (ROM), a random access memory(RAM), a magnetic or optical card, or any type of media suitable forstoring electronic instructions, and each coupled to a computer systembus. While given components of the system have been describedseparately, one of ordinary skill will appreciate that some of thefunctions may be combined or shared in given instructions, programsequences, code portions, and the like.

Preferably, the functionality is implemented in an application layersolution, although this is not a limitation, as portions of theidentified functions may be built into an operating system or the like.

The functionality may be implemented with other application layerprotocols besides HTTPS, such as SSL VPN, or any other protocol havingsimilar operating characteristics.

There is no limitation on the type of computing entity that mayimplement the client-side or server-side of the connection. Anycomputing entity (system, machine, device, program, process, utility, orthe like) may act as the client or the server. There is no limitation onthe type of computing entity that may implement the client-side orserver-side of the connection. Any computing entity (system, machine,device, program, process, utility, or the like) may act as the client orthe server.

While given components of the system have been described separately, oneof ordinary skill will appreciate that some of the functions may becombined or shared in given instructions, program sequences, codeportions, and the like. Any application or functionality describedherein may be implemented as native code, by providing hooks intoanother application, by facilitating use of the mechanism as a plug-in,by linking to the mechanism, and the like.

What is claimed is as follows.

1. Apparatus operating as an intermediary between a first computing entity and a second computing entity, the first computing entity and the second computing entity having established between them an active cryptographic session for transport of encrypted requests from the first computing entity, and encrypted responses from the second computing entity, the apparatus comprising: a processor; computer memory holding computer program instructions executed by the processor during the active cryptographic session to: receive from the second computing entity a first instruction to splice into the active cryptographic session; splice into the active cryptographic session and carry out at least one action with respect to information within one of: an encrypted request, and an encrypted response flowing through the intermediary; receive from the second computing entity a second instruction to shunt out of the active cryptographic session; and shunt out of the active cryptographic session, after which access by the intermediary to information within the encrypted request or the encrypted response is revoked under the control of the second computing entity.
 2. The apparatus as described in claim 1 wherein the active cryptographic session is a TLS session.
 3. The apparatus as described in claim 1 wherein the first instruction includes a decryption key associated with the active cryptographic session.
 4. The apparatus as described in claim 1 wherein the second instruction is associated with a renegotiation of the active cryptographic session.
 5. The apparatus as described in claim 1 wherein the first computing entity is a client application, the second computing entity is an origin server, and the intermediary is an edge server of a content delivery network.
 6. The apparatus as described in claim 1 wherein the at least one action injects into the active cryptographic session content cached at the intermediary.
 7. The apparatus as described in claim 1 wherein the intermediary is restricted from visibility into an encrypted request or encrypted response except upon receipt from the second computing entity of the respective first instruction.
 8. The apparatus as described in claim 1 wherein receipt of the first instruction enables the intermediary to decrypt data but not to contribute data to the active cryptographic session.
 9. The apparatus as described in claim 1 wherein receipt of the first instructions enables the intermediary to perform a write operation with respect to the active cryptographic session.
 10. The apparatus as described in claim 9 wherein the write operation is a one-time write operation. 